1. Field of the Invention
The present invention relates generally to computer systems and more particularly to methods and apparatus for facilitating the testing and verification of integrated circuit designs using simulation tools.
2. Description of the Relevant Art
Because of the complexity of the circuitry in modem integrated circuits (ICs), the design of the circuitry is thoroughly tested before the actual circuit is manufactured. The testing is intended to identify errors in the design of the circuitry so that the errors can be corrected with minimal effort and expense. Typically, this testing is accomplished by simulating the functioning of the circuitry on a computer system using a hardware description language. (References herein to xe2x80x9cHDLxe2x80x9d will indicate a hardware reference language which may be Verilog or any other hardware description language.) The design engineers use an HDL to generate a detailed functional description of the circuitry including, for example, the input signals to be provided to the circuitry and the output signals which are produced in response thereto. The description of the circuitry may comprise descriptions of sub-components or xe2x80x9ccellsxe2x80x9d and the interrelationships between these components. The resulting model can be used to simulate the behavior of the circuitry.
The HDL model of the circuitry is implemented in a simulation system to verify the proper functioning of the circuitry. The simulation system may comprise any one of a number of such systems, one example being the Verilog system, which is well known to those in the art. xe2x80x9cVerilogxe2x80x9d also refers to a particular HDL. The simulation system accepts data which defines the behavior of the circuitry as well as the signals to be input to the circuitry and, in response, generates data corresponding to simulated output signals.
Traditionally, the entire simulation system, including the functional description of the newly designed circuitry, has been written in HDL. Because HDL is used to form a detailed functional description of circuitry such as ASICs (Application-Specific Integrated Circuits), it is by nature a specialized and complex language. With the increasing complexity of these circuits, verification of functionality at the gate level is often insufficient because of the difficulty of observing the internal state of the circuitry at its I/O interface. Further, generating a set of tests for this circuitry can be a daunting task since HDL does not have many of the features which are found in higher-level languages and which make it easier for programmers to handle large software projects. It is therefore desirable to have an interface mechanism which allows tests written in higher-level languages to control a simulation written in HDL.
The need to allow tests to be written in high level languages and then interfaced to the HDL resulted in the development of interface systems such as CVI. CVI is described in U.S. Pat. No. 5,732,247 to Dearth, et al. CVI allows tests to be written in higher-level languages such as C and C++ and serves as an interface between the HDL simulation system and the higher-level-language test system. CVI translates the test statements into simulated bus activity in the simulation system. CVI is particularly useful in the development of simulation systems because the verification engineers who write the test procedures normally are not the same engineers who write the functional description of the new circuitry.
One important aspect of the CVI mechanism is that it allows the design of device objects which present a low-level register interface to the test writer. This is useful because it presents the test writer with a consistent interface style shared by all transactors and provides a consistent documentation format. The low-level register interface is also intuitively appealing because the register model mimics modem computer system operation and is well understood by programmers. The CVI mechanism introduces a device driver abstraction which shields users from the low-level details of complex circuitry. This level of abstraction again provides test writers with a consistent view of many dissimilar devices. The device drivers in the simulation system maintain state information regarding the devices in order to simplify control and scheduling of the operations of the device.
The issues surrounding the abstractions outlined above may be solved by various embodiments of the system and method of the present invention. One embodiment of the invention comprises a simulation system configured to model a circuit design and a test system configured to operate in cooperation with the simulation system. The systems comprise one or more software applications which may be stored on computer-readable media such as magnetic disks or tape, and which may be executed on a suitable computer system.
In one embodiment, a mechanism is provided to facilitate testing of circuitry designs in a device simulation environment. The mechanism is implemented in a high-level programming language and is used in conjunction with a simulation system, which is written in an HDL, and a simulation system interface. The mechanism simplifies test writing by performing a function similar to that of an operating system device driver. The mechanism provides consistent high-level interfaces to device objects, device object information hiding, simplification of random environment testing, effective parallel operation without threading, state driven test writing style, encapsulation/aggregation of convenience routines, simplification of device object configuration management and storage of parameters for convenience routines in class member variables.
One embodiment of the invention comprises a hierarchical set of transaction classes. The uppermost class defines a base transaction. All transaction classes inherit from this class. Below the base transaction class are a device transaction class and a system transaction class. The device transaction class is associated with the device class through an object reference. The system transaction class is used to collect convenience routines. The system transaction class contains pointers to each of the required device transaction classes. The next level in the hierarchy includes one or more configuration transaction classes which reference selected device objects.
This class structure provides a mechanism through which a test writer can easily write and maintain program code to test a simulated device. The system transaction class provides an infrastructure upon which the test writer can build the code. The system transaction class contains pointers to device transaction objects for all of the devices in the simulated system and aggregates the convenience routines which may be useful in writing the tests. The system transaction class is not instantiated directly, but is instead used as the basis for the configuration transaction classes. Each configuration transaction class represents a selected subset of the devices in the simulated system and is instantiated to test transactions involving the corresponding devices. Because the configuration transaction classes use object references to the device objects, the user is forced to supply the appropriate device objects at the time of instantiation and the compiler is therefore able to perform static type checking. The configuration transaction classes thus enable the test writer to use all of the convenience routines defined in the system transaction class while only instantiating those device objects which are needed for the corresponding configuration. At the same time, the test writer can more easily maintain the test code because all of the convenience routines are written only once and collected in the system transaction class.